Various classes of graphical models describe computations that can be performed on computational hardware, such as a computer, microcontroller, FPGA, and custom hardware. Classes of such graphical models include time-based block diagrams such as those found within Simulink® from The MathWorks, Inc. of Natick, Mass., state-based and flow diagrams, such as those found within Stateflow® from The MathWorks, Inc. of Natick, Mass., entity flow network diagrams such as those found within SimEvents from The MathWorks, Inc. of Natick, Mass., data-flow diagrams, circuit diagrams, and software diagrams, such as those found in the Unified Modeling Language. A common characteristic among these various forms of graphical models is that they define semantics on how to execute the diagram.
Historically, engineers and scientists have utilized graphical models in numerous scientific areas such as Feedback Control Theory and Signal Processing to study, design, debug, and refine dynamic systems. Dynamic systems, which are characterized by the fact that their behaviors change over time, or the fact that their states change or the fact that their behaviors change due to a system environment, are representative of many real-world systems. Graphical modeling has become particularly attractive over the last few years with the advent of software packages such as Simulink® from The MathWorks, Inc. of Natick, Mass. Such packages provide sophisticated software platforms with a rich suite of support tools that makes the analysis and design of dynamic systems efficient, methodical, and cost-effective.
A dynamic system, either natural or man-made, is a system whose response at any given time is a function of its input stimuli, its current state, the current time, and other input parameters. Such systems range from simple to highly complex systems. Physical dynamic systems include a falling body, the rotation of the earth, bio-mechanical systems (muscles, joints, etc.), bio-chemical systems (gene expression, protein pathways), weather and climate pattern systems, etc. Examples of man-made or engineered dynamic systems include: a bouncing ball, a spring with a mass tied on an end, automobiles, airplanes, control systems in major appliances, communication networks, audio signal processing, nuclear reactors, a stock market, etc.
Professionals from diverse areas such as engineering, science, education, and economics build graphical models of dynamic systems in order to better understand system behavior as it changes with the progression of time. The graphical models aid in building “better” systems, where “better” may be defined in terms of a variety of performance measures such as quality, time-to-market, cost, speed, size, power consumption, robustness, etc. The graphical models also aid in analyzing, debugging and repairing existing systems (be it the human body or the anti-lock braking system in a car). The models may also serve an educational purpose of educating others on the basic principles governing physical systems. The models and results are often used as a scientific communication medium between humans. The term “model-based design” is used to refer to the use of graphical models in the development, analysis, and validation of dynamic systems.
Graphical modeling environments such as Simulink®, assist in simplifying the process of designing, simulating, and implementing dynamic systems. A graphical model is a representation of a real-world system through a graph containing nodes (i.e. blocks) interconnected by arcs (i.e. lines). Blocks are functional entities that perform mathematical operations, transformations or both on the data and information being processed by the system. The lines, often referred to as signals in the art, represent streams of information, such as data, data types, timing information, and control information, flowing into, out of, and between various blocks. Signals in current graphical model environments have a number of properties, such as data dimensions (i.e., signal dimensionality), data type, range of signed and unsigned values, scaling, and precision, amongst other properties. Signal data can be organized into a one-dimensional data structure for example, a vector or can be organized into a two-dimensional data structure, for example, a matrix, or can be organized into a three-dimensional or higher-dimensional data structure.
Graphical modeling environments, such as the technical computing environment of MATLAB® from the MathWorks, Inc. of Natick, Mass., can provide a “model-based design” approach to designing an implementation. The term “model-based design” is used to refer to a model acting as a design. A model-based design may be used as a design specification for an implementation, such as an implementation of an algorithm in hardware circuitry or the implementation of code to run on a computer. A graphical block diagram modeling environment can produce designs in graphical block diagram form to specify computations that can be performed on computational hardware such as a general purpose processor, microcontroller, DSP, FPGA, PLD, or ASIC. That is, a model-based design is well suited for use as a design specification, for the model-based design can drive the building process of an implementation of the design. For instance, the model-based design can act as a specification from which to automatically generate code from a graphical model in a graphical modeling environment.
There are some limitations associated with conventional model-based design tools. For example, the user cannot specify externally known limitations regarding the precision of a signal. For instance, a user cannot specify that a signal represents a temperature reading that is accurate to +/−0.125 degrees Celsius. In addition, a user cannot specify externally known requirements regarding the precision of a signal. For example, suppose that a signal controls the aiming of a laser in a laser printer and there is a design goal to have 600 dots per inch accuracy. Conventional model-based design tools do not provide a mechanism for a user to specify this externally known precision requirement.
An additional limitation of conventional model-based design tools is that they do not allow a user to enter externally known limitations regarding rates of change for a signal and for the derivatives of the signal. For instance, suppose that a user knows that a signal representing the temperature of an engine block never changes faster than degrees per second. With conventional model-based design tools, there is no way of specifying this limitation regarding the rate of change of the signal a priori.
As another example, consider a DC motor that is used to move a power window of an automobile up and down. In its operation, the current that the motor draws may range from −15 Ampere to 15 Ampere. If the measurement instrumentation has a 2% accuracy, the value of the current is known in a range of +/−300 milli-Ampere. The measurement may be coded into a 16 bit representation which, for a range of 30 Ampere would result in a precision of 0.4 milli-Ampere. This measurement may be used in the control of the DC motor voltage so that the window never exerts a force larger than 100 Newton. Again the 16 bit representation may correspond to a higher precision than what the actuator instrumentation is rated for, which may be in the order of +/−2 Newton.
In this DC motor example, the 300 milli-Ampere range as well as the +/−2 Newton range are properties of system behavior that have an external origin, i.e., they are not inherent in the model. Depending on whether they represent design goals or implementation constraints, they can be considered requirements or limitations, respectively. These two different aspects of the design are related to disjoint activities in the overall design process and are part of the opposite ends of the overall design flow. That is, the manner in which limitations arise and are defined is treated different from the manner in which requirements arise and are defined. It is often unclear as to how design practices transfer from limitation to requirement handling and vice versa. With conventional model-based design tools such external requirements and limitations related to precision, range, rate-of-change, etc., cannot be specified.
Model-based design tools provide a limited ability to derive signal properties from other known values. There are a number of derived signal properties that are not available with current model-based design tools. For example, conventional model-based design tools do not allow derived precision limitations to be automatically obtained. Similarly, they do not allow derived precision requirements to be obtained.
Model-based design tools provide certain varieties of instrumentation, such as logging of signal values, logging of simulation maximums and minimums and logging overflow events. Conventional model-based design tools, however, do not provide instrumentation that collects a simulation Nth discrete derivative maximum and/or minimum for signals. That is, conventional model-based design tools cannot collect derived maximum and/or minimum values based on one or more temporal derivative limits of the values. Likewise, conventional model-based design tools cannot capture an Nth temporal derivative. Those skilled in the art will appreciate that as used herein N can be any integer larger than zero(0).
Conventional model-based design tools have limited diagnostic capability. For instance, these conventional model-based design tools do not provide the ability to diagnose failure to meet a design precision requirement or exceeding a design limitation.
Conventional model-based design tools are also limited in automatic scaling techniques that are applied to fixed point signal values to set binary points for the values. These conventional model-based design techniques are also limited in the variety of techniques that are available for the selection of data types for signals.